iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 16
0
Modern Web

前端開發 30 個問題系列 第 16 篇

How browser works (3) - TCP/IP model

  • 分享至 

  • xImage
  •  

前言
2020 秋天,我將用 30 天的時間,來嘗試回答和網路前端開發相關的 30 個問題。30 天無法一網打盡浩瀚的前端知識,有些問題可能對有些讀者來說相對簡單,不過期待這趟旅程,能幫助自己、也幫助讀者打開不同的知識大門。有興趣的話,跟著我一起探索吧!

Create connection

在上一篇文章當中提到,當我們在瀏覽器當中輸入網址之後,就會透過各種 DNS server,來幫我們找到目標網站的 IP address。接下來就是要建立通訊連線,讓我們可以獲得目標網站的資源,或是發送更多的請求。

要建立通訊連線也是一件不簡單的事情。在過去沒有電話和網路的時代,遠距離通訊就只能靠信件,首先要先把資訊寫在紙上,然後用信封裝起來,信封上面需要寫著收件人的姓名與地址,接著,就要透過郵政系統,把這筆資訊送到對方手上。至於郵政系統本身,又有許多的規則與規定需要遵守,才能確保郵差能夠將資訊送到對的地方。

即便進入了網路世代,通訊的本質還是差不多,需要將資訊打包,遵守一定的方式與規定,傳遞到對方的手上。在過去有郵政系統,在網路世界,有 ISO 推出的 Open Systems Interconnection model (OSI model) 可以作為參考。

OSI model

OSI model 是一個概念模型,它建立了一個框架,說明資訊該如何從應用程式、透過網路連線、經過實體的傳輸線,最後來到目標網站或主機。在 OSI model 當中有七層的架構,每一層都有其相對應的 protocols,定義了資訊傳出的規範。

不過 OSI model 只是個概念框架,並沒有說明實際網路連線與傳輸該如何實現。目前實際上真正實現的是 TCP/IP model 所規範的內容。

TCP/IP model

相較於 OSI model 的七層架構,TCP/IP model 只有四層,可以說是簡化版的 OSI model。雖然說是簡化,但實際上整體的架構還是不脫 OSI model 的內容。

在下圖可以看到 OSI model 的七層架構,與 TCP/IP 四層架構的對應關係:

在 Application Layer 當中的 protocol,定義了應用程式透過網路交換資訊的格式,常見的有 HTTP, HTTPS, FTP (檔案傳輸), POP3 (接受電子郵件), SMTP (發電子郵件), TELNET, SSH 等等

在 Transportation Layer 當中的 protocol,定義了傳輸資料的品質(可靠性與順序性),譬如常見的 TCP 與 UDP 協議。

而 Internet Layer (或 Netword Layer) 當中的 protocol 則定義了資料如何在一個單一網路上傳輸並可以抵達目的地。這裡其實就是靠著先前提到的 IP address 來找到目標位置。

最後的 Network Layer 則定義資訊如何透過韌體與硬體間傳遞與接收。

不過在開發網路應用程式的過程當中,我們大部分關注可能都在 Application Layer 的上,因為 Trasportation 與 Internet Layer 的實現,多半直接靠作業系統自動完成,Network Layer 則靠電腦與網路連線設備自動完成。

雖然如此,不過今天還是想來聊聊 Trasnportation Layer 當中的 TCP 與 UDP 協議,瞭解網路連線是如何被建立的。

TCP vs. UDP

TCP 和 UDP 都是透過同樣的方式傳輸資料,並透過 IP 找到目標。不過兩者因為性質上的差異,所以應用場景也有很大的不同。

TCP 用於需要「可靠通訊」的場景,「可靠通訊」的意思是,資料在傳輸的過程中不會遺漏,而且有正確的順序性。大部分情況下我們都需要 TCP 來保證通訊的可靠性。

相對於 TCP,UDP 有時也被稱作「不可靠的通訊」。這樣我們可能會想,既然不可靠,為什麼我們還會使用 UDP 呢?因為 TCP 為了保證「可靠」,必須依賴相對應的機制,而這些機制會使用較多的資源,並降低傳輸效率。而在某些使用場景,像是網路電話、視訊會議、遊戲等,更看重傳輸速度與即時性,品質方面可以稍微犧牲,因此就可以採用 UDP 的傳輸方式。

另一方面,UDP 可以做到一對多的廣播功能,而 TCP 就只能夠一對一通訊。

TCP 3-Way handshake & 4-Way handshake

TCP 為了在通訊連線前,確認對方可以準備接收訊號,以及在斷線前,確認對方準備好離線,因此發展出了連線前的 3-way handshake 與離線前的 4-way handshake 機制。簡單說明如下:

連線前的 3-way handshake

  1. CLIENT: 發送通訊連線請求
  2. SERVER: 確認允許連線
  3. CLIENT: 確認連線

離線前的 4-way handshake

  1. CLIENT: 發送通訊斷線請求
  2. SERVER: 確認收到斷線請求,並繼續傳送最後的資訊
  3. SERVER: 最後的資訊傳送完畢,確認可以斷線
  4. CLIENT: 確認斷線

End

現在我們已經知道如何連線,接下來,就要來看看如何發送 HTTP 請求。我們明天見啦~

Ref


TD
Be curious as astronomer, think as physicist, hack as engineer, fight as baseball player

More about me

"Life is like riding a bicycle. To keep your balance, you must keep moving."


上一篇
How browser works (2) - DNS
下一篇
How browser works (4) - HTTP message
系列文
前端開發 30 個問題 共 31 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言